初探 GitLab Workflow & GitLab Flow

第 11 屆 iThome 鐵人賽

DAY 6

DevOps

和艦長一起 30 天玩轉 GitLab系列第 6 篇

11th鐵人賽 devops gitlab

Cheng Wei

2019-09-19 02:16:45

20424 瀏覽

分享至

按著昨天的故事，我們假想中的產品開發團隊已經順利成立了，但在團隊開始投入開發工作之前，需要先和團隊成員們確認接下來團隊的工作分配、Workflow 以及團隊協作方式。

在我們假想的背景故事中，這是一個全新籌組的團隊，負責開發公司全新的產品。因此作為故事中的關鍵主管 Dev Leader 早已在心中作出決定，就是要採用 GitLab 作為團隊合作協作的核心工具，讓團隊直接採用 GitLab Workflow 作為團隊的 Workflow。（謎之音：故事不這樣演下去，艦長沒辦法繼續介紹 GitLab 啊～）

GitLab Workflow 簡介

（2024.9.29 更新：再次友善提醒 GitLab Workflow 這個詞，目前已經變成 GitLab 開發的 VSCode extension。如果你想要找的是 VSCode extension 的使用方法，這篇文章不是你想要的內容！）

GitLab 公司認為，一般來說從創意發想（Idea）開始直至產品上線並收集回饋意見（Feedback）為止，我們可以將軟體的開發流程（Workflow）大致劃分為 10 個步驟，10 個步驟彼此相連並且與團隊的生產力息息相關。而 GitLab Workflow 即是以 GitLab 為核心工具，借助 GitLab 的產品生態系，讓開發團隊能夠有效地串連這 10 個步驟，迅速搭建團隊的 Workflow。

下面就來說明這 10 個步驟有哪些重點，以及 GitLab 產品生態系又是如何在每個步驟提供支援：

Idea: 除了面對面的實體會議，線上的聊天討論空間中的某個想法，也許亦有機會成為產品創意發想的養分。現今多數的開發團隊皆十分流行使用 Slack 這一類的工具，作為團隊的溝通協作工具，這些工具不僅在公事上為團隊提供了更方便、有效的溝通媒介，甚至於私它們也能為團隊的凝聚提供助益。而 GitLab 早在 2015 年便注意到團隊溝通協作工具的重要性，自 GitLab 7.14 版開始，GitLab 便將 Mattermost 這套類似 Slack 的 Open Source 團隊溝通協作工具納入 GitLab 的工具生態系。因此可以說打從團隊預備在線上溝通、討論產品概念的那一刻開始，GitLab 就已在背後支持著團隊了。
Issue: 有了天馬行空的 Idea 之後，接著要將其轉變成更具體明確的 Story 或 Issue。而 GitLab 則提供了完整的 Issue Tracking 功能，GitLab 的 Issue Tracker 既可作為獨立的 Issue 討論空間，亦可以與實際程式碼之 commit 紀錄建立關聯。
Plan: 延續步驟二，當 Story 或 Issue 被逐一建立完畢之後，不論你要走瀑布式、敏捷或隕石開發，在進入實際的程式開發工作之前，當然要先有所「計畫」，決定工作的優先順序。而 GitLab 的 Issue Tracker 可以直接搖身一變成為 Issue Board——即任務版（Task Board），幫助團隊一覽開發工作進行狀況的全貌。當然工具是隨人靈活使用的，雖然 Issue Board 尚欠缺仿間數位看板（KanBan）軟體的某些進階功能，但如果你習慣用看板方法來管理專案，你還是能在有所變通的狀況下，以看板方法的方式來使用 Issue Board。
Code: 有了計畫之後，下一步當然就是動手撰寫程式。
Commit: 程式撰寫完畢之後，即可送入版本控制之中。這應該不需多說，GitLab 的核心功能就是 Git 版本控制。
Test: 當程式碼被提交至版本控制系統之後，接著就是測試。這也就是 GitLab CI 服務上場的地方了。
Review: 當 CI 自動化建置、測試都通過之後，在將程式碼 Merge 至主要的 Branch 之前，需要先進行 Review 的動作。而 GitLab 的 Merge Request 功能，則提供了良好的機制，讓團隊可以針對 Merge Request 進行討論。
Staging: 程式順利 Merge 之後，即可將程式自動部署至 Staging 或 Production-like 的環境，藉此再次驗證程式是否正確運行。除了 GitLab CI 既有的 CI / CD 功能之外，GitLab CI 目前更擁有名為 Auto DevOps 的神奇功能，讓 CI / CD / 自動化部署更加自動、順暢與便利。
Production: 續上，當程式在 Staging 環境亦順利通過驗證，最後即可部署至 Production 環境供使用者使用。GitLab CI 目前已有 Environment 的功能，若是你有妥善規劃 Environment 與 CI / CD 流程，那麼對團隊而言 Production Deploy 也不過就是按下 GitLab 操作介面上的按鈕那樣簡單的一件小事。
Feedback: 這是最後、也是非常重要的一個步驟，它能幫助產品及團隊自身得以繼續不斷的「持續改善」。GitLab 目前已有 Cycle Analytics 功能，可以針對專案進度、工時的控管狀況提供數據分析，如團隊能善用這項功能，即可幫助團隊發覺目前開發流程中的瓶頸點，讓團隊能有所本的向著「持續改善」的道路前進。

大致認識 GitLab Workflow 的 10 個步驟其概況後，其實我們會發現這條 Workflow 與其他常見的 Workflow 也並無太大差異。重要的關鍵還是在於到底 GitLab 在建構產品生態系時，為這條 Workflow 提供了哪些合適的功能，而這些功能又是如何幫助團隊得以順利上手運用這套 Workflow。

關於 GitLab Workflow 實際會使用到哪些 GitLab 功能且該如何使用，這些內容我們會隨著文章的進度，再逐一說明。

GitLab Flow

知道 GitLab Workflow 的 10 個步驟後，接著要說明另一項與 Workflow 十分相關的事情，即是我們的假想團隊這次將採用的 Git 分支策略——GitLab Flow。

GitLab Flow 是 GitLab 公司由 GitHub Flow 再發展而來的。GitLab Flow 保留了 GitHub Flow 的分支策略，依然有 feature branch 與 master branch，但在 master 之外再增加專門用來配合交付與部署的 branch，例如 pre-production branch、production branch 或特定版號 -stable。

Production branch：用來幫助團隊明確知道目前正式上線的程式碼是哪一個版本。因此團隊可以按著開發步調持續地推進開發工作，開發進度依然按照 Github Flow 的做法，由 feature branch 合併至 master branch。當程式要正式上線時，才根據要交付的範圍，從 master branch 合併至 production branch，同時在 production branch 即可搭配 GitLab CI 功能觸發 CI Job - production deploy。
Environment branch：續上，GitLab Flow 建議你除了多增加 production branch 對應正式環境之外，你也可以根據不同的部署環境額外建立對應的 branch。例如也許你的正式環境是一個龐大的分散式架構，因此在部署到正式環境之前，為了避免出現預期之外的問題，還需要先在和正式環境類似但規模較小的 pre-production 環境進行測試與驗證；在此情境下，你不妨就增加一個 pre-production branch 對應 pre-production 環境。同理，也許今天某公司可能需要定期展示最新功能給投資人觀看，需要一個環境會定期部署最新版本的程式，GitLab Flow 建議即可增加一個 vc branch 來管理它。
Release branch：最後，如果你的程式並非是直接部署於某個環境，而是直接對外發佈（release），那麼 GitLab Flow 的作法是不一定要建立 production branch，而是改為根據每次的 release 建立對應的 release branch。這麽做的目的在於讓 master branch 能夠持續地穩健前進，而 release 出去的分支既能保持當下版本在功能上是獨立 stable 的狀態，又能適度的跟隨 master 修補程式漏洞。

根據上面的內容，我們可以了解到 GitLab Flow 保留了 feature branch 與 master branch，使得開發團隊能專注於開發工作。同時額外新增的 production、environment 及 release branch，再搭配 GitLab 的 CI、merge request、issue tracking、Environment 等功能，將能幫助開發工作和交付部署工作之間能做出適度的切分，避免相互影響。